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(54) Method and apparatus for dynamically loading method call exception code 



(57) A method for handling method calls in a cli- 
ent/server computer system includes the step of receiv- 
ing at a server computer a method call generated by a 
client computer. The server computer then attempts to 
execute the method call and subsequently generates an 
exception. The exception is passed to the client compu- 
ter. The client computer matches the exception to 
exceptions in an exception list stored in the client com- 
puter to obtain an exception object identifier. The excep- 
tion object identifier is used to load exception code into 
the client computer. The exception code is then proc- 
essed. Thus, the exception code need not be loaded at 
the time of generating the method call. Instead, it is only 
loaded when it is required at run time. 
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Description 

Brief Description of the Invention 

s This invention relates generally to client/server computer networks. More particularly, this invention relates to a 
technique for loading method call exception code into a client computer only when it is required at run time. 

Background qf the Invention 

ro In a cfientfeerver computer network, the user of a client computer requests the execution of an object In particular, 
the user requests the execution of a method associated with the object Frequently, the object is not stored locally on 
the client computer. Thus, a remote procedure call (RPC) must be made to a server computer on which the object 
resides. In most cases, the server computer executes the requested method to generate a result The result is then 
passed to the client computer. However, when the server computer cannot execute the requested method or can only 

75 execute a portion of the requested method, an exception is said to exist In this case, the server computer notifies the 
client computer of the exception. It is then incumbent upon the client computer to interpret the nature of the exception 
and take corrective action. 

In many distributed computer systems that support remote procedure calls, for example computer systems using 
the SOLARIS™ operating system in conjunction with the JAVA™ virtual machine environment, both from Sun Microsys- 

20 terns®, Inc.. Mountain View, California (SOLARIS™, JAVA™ and Sun Microsystems® are trademarks or registered 
trademarks of Sun Microsystems. Inc. in the United States and other countries), when a client computer requests the 
execution of a method in an object (sometimes called invoking an object method), the client computer instantiates all 
the exception code associated with that method. The exception code might be stored locally on the client computer, but 
in many cases the exception code must be retrieved from a remote computer. Consequently, in most cases, by invoking 

25 an object the client computer must retrieve exception code from a remote computer, initiating communication with the 
remote computer and exchanging information with it is a relatively time consuming operation. 

Since in most cases the invoked method is successfully executed, the method exception code is not used by the 
client computer. Thus, the client computer expends valuable time loading exception code that is not necessary. In view 
of this situation, rt would be highly desirable to provide a technique for loading method call exception code only in the 

30 event that it is needed at run time. 

Summary of the Invention 

An embodiment of the invention includes the step of receiving at a server computer a method call generated by a 
35 client computer. The server computer then attempts to execute the method call and subsequently generate an excep- 
tion. The exception is passed to the client computer. The client computer matches the exception to exceptions in an 
exception list stored in the client computer to obtain an exception object identifier. The exception object identifier is used 
to load exception code into the client computer. The exception code is then processed in order to handle the exception. 
Thus, the exception code is not loaded at the time of generating the method call. Instead, it is only loaded when it is 
40 required at run time. 

The apparatus of the invention may include a client computer that generates a method call. A server computer 
receives the method call from a transmission channel connected between the client computer and server computer. 
The server computer attempts to process the method call and thereafter generates an exception. The exception is 
passed over the transmission channel to the client computer. The client computer matches the exception to a set of 

45 stored exceptions. The matched exception is associated with an exception object identifier. The exception object iden- 
tifier is used to load exception coda The client computer then processes the exception code, thereby responding to the 
exception generated by the method call. 

The client computers operate much faster because they load less information when a method is invoked. Specifi- 
cally, they only load the code for the method call. In the relatively unusual event that the method call is unsuccessful, 

so then the method exception code associated with the method is expeditiously loaded. 

Brief Description of the Drawings 

Examples of the invention will new be descrbed with reference to the accompanying drawings, in which: 

55 

FIGURE 1 illustrates a client/server computer topology. 

FIGURE 2 illustrates the processing associated with the apparatus of Figure 1 . 

FIGURE 3 illustrates the processing steps associated with the protocol recognition methodology of an embodiment 
of the invention. 
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FIGURE 4 illustrates an example of a data structure that may be used in practicing the disclosed technology. 
FIGURE 5 is a generalized representation of a data structure that may be used in practicing the disclosed technol- 
ogy. 

FIGURE 6 illustrates processing steps associated with the dynamic loading of exception code, in accordance with 
s one embodiment of the invention. 

Like reference numerals refer to corresponding parts throughout the several views of the drawings. 

Detailed Description of the Invention 

10 

Figure 1 illustrates a client/server computer apparatus 20 incorporating the technology of the present invention. 
The apparatus 20 includes a set of client computers 22A-22N, which are each linked to a transmission channel 23. The 
transmission channel 23 generically refers to any wire or wireless link between computers. The client computers 22A- 
22N use the transmission channel 23 to communicate with a server computer 24, or other server computers designated 
75 by server computer 24N. 

Each client computer 22 has a standard computer configuration including a central processing unit (CPU) 30 con- 
nected to a memory 32. which stores a set of executable programs. The executable programs in this exemplary system 
include at least one client application program 34, client stubs 38, client subcontracts 40, and an operating system 42. 

The client application program 34 is any application-level program, such as an application program that the user of 
20 a client computer 22 interacts with. The client stubs 38 receive procedure calls by the application program 34 requesting 
the execution of specified methods of specified objects. The purpose of the client stubs 38 is to access objects that are 
implemented in other address spaces, such as at server computer 24. 

The client subcontract programs 40 and server subcontract programs 58 control the basic mechanisms of object 
invocation and argument passing. They control hew object invocation is implemented, how object references are trans- 
25 mitted between address spaces, hew object references are released, and similar object runtime operations. For exam- 
ple, when a client invokes an object of a given subcontract the subcontract implements the object invocation by 
transmitting the request to the address space where the associated object is located, commonly the server computer 
24. 

The client subcontract programs 40 perform a marshal operation to transmit an object invocation (i.e., a remote pro- 

30 cedure call) to another address space. A corresponding unmarshalling operation is performed by a server subcontract 
58 on the server computer 24. The client subcontract programs 40 also perform unmarshal operations when receiving 
a reply (such as the results generated from a method call) from another computer, say the server computer 24. An oper- 
ating system 42, such as the Sun Microsystem's SOLARIS operating system, underlies the operations of the client 
application programs 34, the client stubs 38, and the client subcontracts 40. 

35 The server 24 has a configuration analogous to that of the client computers 22. The server 24 includes a CPU 50 
and an associated memory 52. The memory 52 stores server application programs 54, server stubs 56, server subcon- 
tract programs 58, and an operating system 60. As indicated above, the server stubs 56 handle incoming method invo- 
cations on an object and call the specified method to perform the operation. As also indicated above, the server 
subcontracts 58 perform data marshalling and other operations to support the transport of method invocations and the 

40 resulting return messages between the server 24 and the client computers 22. 

The operations of the apparatus of Figure 1 are more fully appreciated with reference to Figure 2. Figure 2 illus- 
trates the client computer 22A, the transmission channel 23, and the server 24 of Figure 1 . As indicated above; a client 
application 34 invokes a specified method of an object in a different address space using a remote procedure call. The 
remote procedure call is passed by the client stubs 38 to the client subcontract 40, which packages the remote proce- 

45 dure call for transport on the transmission channel 23. The server subcontract 58 of the server 24 receives the informa- 
tion and unpackages it. The server subcontract 58 then passes the information to the server stubs 56. The server stubs 
56 access the server application programs 54, which are the previously descrtoed object methods. More specifically, a 
specified server stub 56 makes a procedure call to execute a specified method of the invoked object The execution of 
the method produces a set of results, herein called a reply, which is then passed back to the server subcontract 58 and 

so the communication path is reversed, as indicated by the arrows of Figure 2. 

Block 70 of Figure 2 illustrates the components associated with an Object Request Broker (ORB) of the invention. 
As incficated above, a wide variety of communication protocols are used on ORBs. The use of different protocols on dif- 
ferent ORBs results in difficulties when a server attempts to recognize incoming object requests. 

The general architecture and processing associated with the embodiment has now been disclosed. Attention pres- 

55 errtiy turns to a more detailed consideration of the architecture of the embodiment, the processing of the embodiment, 
the distinctions between these elements and corresponding elements in the prior ail, and the advantages associated 
with the disclosed technology. 

As shown in Figure 2, a client subcontract 40 uses a protocol-dependent method descriptor to request a method 
associated with an invoked object. More particularly, the client subcontract 40 uses a marshal buffer that obeys a 
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selected on-the-wire data format. For example, to identify a given method "X". one protocol might use a value of "XXX", 
another might use a value of "@@@::123::XXX W P and another might use an integer value "123456", where the value is 
the output of a hash function on the method name. The client stub 38 passes to the client subcontract 40 a list of pro- 
tocol-dependent values from which the client subcontract 40 computes the protocol-dependent method descriptor. 

5 Thus, when a set of client conrputers 22A-22N are connected to a server 24, the server 24 must process each pro- 
tocol. Separate server subcontracts 58 (not shown) are necessary to accommodate each of these protocols. In the prior 
art, each server subcontract 58 has a set of corresponding server stubs 56. Thus, to support ORBs with multiple pro- 
tocols, a server 24 should have different server stubs 56 for each protocol, resulting in a large set of server stubs 56. 
Consequently, it can be readily appreciated that the use of different ORB protocols can result in unwieldy requirements 

10 for the server 24. 

In accordance with the present embodiment, when the server subcontract 58 receives an incoming method call it 
unmarshals the method descriptor in a way that is specific to the subcontract's protocol, ft then tries to match the 
method descriptor with each of the entries in a list of protocol-dependent values. Protocol-dependent values can be 
character strings, numeric values, as well as other types of parameter values. Different protocols may use different 

75 matching functions to compare the method descriptor with the list of protocol-dependent values. The matching function 
may by a string comparison, a hashing function, or other technique specified by the server subcontract 58. When a 
matching protocol-dependent value is identified, the server subcontract 58 can then associate it with an index value. 

As shown in Figure 2, the index value is passed to protocol-independent server stubs 56 that can invoke the 
method corresponding to the index value. In this way, the protocol dependencies of the individual object references are 

20 insulated from the protocol-independent server stubs 56. Consequently, protocol-independent server stubs 56 can be 
used with any type of object request broker 70. Furthermore, a single compiler may be used to generate the protocol- 
independent server stubs 56. 

Thus, unlike the prior art, the present embodiment provides a server 24 that recognizes a variety of ORB protocols. 
Moreover, it performs this function in a highly effective manner by using a single set of protocol-independent server 

25 stubs 56. Note that to support this technique, the marshalling and unmarshalling operations commonly employed by 
prior art stubs are performed by the client subcontract 40 and server subcontract 58 of the invention. This transfer of 
processing and the use of an index value to provide protocol-independent server stubs constitute differences between 
the prior art and one embodiment of the present invention. Thus, this embodiment of the present invention can be suc- 
cessfully implemented in existing architectures and processes, once these processing differences are accommodated. 

30 Figure 3 provides a detailed illustration of the processing steps described in the foregoing paragraphs. The first 
processing step of Figure 3 is that the server subcontract identif ies a method descriptor in a method call (block 80). As 
indicated above, the client computer produces a method call, which is ultimately packaged in a marshal buffer as a set 
of information. The content of the information is contingent upon the client subcontract that has marshalled the informa- 
tion. The corresponding subcontract at the server unmarshals the information and recognizes, within the information, 

35 the method descriptor. 

The next processing step is for the server subcontract to select a protocol-dependent value that matches the 
method descriptor (block 82). This operation may be illustrated with reference to Figure 4. Figure 4 shows a 
DescriptorJJst of protocol-dependent values. This list includes N subset lists. Each subset fist identifies a set of proto- 
col-dependent values that may be used to identify a single method. Each subset list has j entries. In Figure 4, these 

40 entries are shown as DescriptorJJstjM through DescriptorJJsMJ. In Figure 4, DescriptofJjst_1_l is associated 
with an Interface Definition Language (IDL) Short Name. IDL is a standard used in the art. That is, one entry in the list 
is the IDL short name for the invoked method. The IDL Short Name is an ORB protocol name used in the art The same 
list shows that Descriptor JJst_1_2 is associated with an IDL Long Name. That is, this entry in the list is the IDL long 
name for the invoked method. The IDL Long Name is another ORB protocol name used in the art The third entry in the 

45 subset list is Descriptor_LisM_3. which has a repository ID. The repository ID is a name used in another ORB protocol 
in the art. Examples of these different protocols include the following statements: 

u get_weak_comparator w (IDL Short Name), 
so * : : comparator : weakcomparable: :get_weak_comparator w 

(IDL Long Name), and 

tt n>L:/comparator/weakj^ 
55 (Repository ID), 



which are used to invoke the operation: 
ge£_weak_comparator. 
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As indicated in Figure 4, alternate designations may also be used in the list of protocol-dependent values. In addi- 
tion, the designations shewn by example herein need not be used. In any event using the format established by the IDL 
standard and other industry standards and practices, it is possfcie to predict the manner in which most method descrip- 
tors will be implemented by arty reasonable protocol. 

The following pseudocode is used asa simple example to illustrate how the descriptor list may be searched. 

(1) i-0 

(2) match = false 

(3) repeat 

(4) i = i + 1 

(5) if Match j> (Method_Descriptor, DescriptorListi J) 

(6) Then Match = True 

(7) until Match 

(8) call operation_Table(i) 



Lines (1) and (2) provide initialization. Line (3) is the entry into a processing loopi Line (4) provides initialization 
within the processing loop. Line (5) tests for a condition. Namely, the code tests if the unmarshalled 
"Metrtod_Descriptor" of the method call matches the "jth" entry of the TtrT subset list (DesciiptorJJsUJ) of the proto- 
col-dependent fist The "jth" entry, say the IDL short name, is Known from the server subcontract 58 to be the one to 
compare for this protocol. The "ith" value is an incremented value that allows each subset descriptor list 
(DescriptorJJsM through DescriptorJJst_N) to be tested. The term "Match_p" refers to the matching function that is 
used to compare the Method_Descriptor to the list entry. For instance, "Match _p" might specify a simple string compar- 
ison between values, or it might specify the comparison of hash values. The definition of "Match u>" is provided by the 
server subcontract 58. 

If the condition is met, then a match is found, otherwise, the next subset list 1" is accessed. When a match is found, 
then line (8) provides a call to an operation table of the server stubs (56). Note that the value V when a match is found 
is the value passed to the server stubs. This value corresponds to a subset of the searched list, and this subset is asso- 
ciated with a single method that has been called. Thus, the code at line (8) illustrates the next processing step of Figure 
3, namely that the server subcontract passes an index value to the server stubs (block 86). 

Once the server stubs receive the index value, they rely upon an operation table 100, shown in Figure 4, to invoke 
the method specified by the index value The operation table is preferably implemented as a case table that has a set 
of processing steps associated with each case value V. When the value V is received, the method specified by the 
value is executed (block 88). Figure 4 illustrates a simple set of processing steps to achieve this result The first step is 
to execute method i, and the second step is to load all resulting messages (the reply) into the marshal buffer. The final 
processing step shewn in Figure 3 is for the server stubs to pass the reply generated from the execution of the method 
to the server subcontracts (block 90). 

Figure 5 illustrates that the ernbodirnent supports the exceptions associated with method calls. In prior art systems 
of the type discussed above, exception code associated with a method is loaded before the method is invoked. For 
example; when a method is invoked in a prior art system, the client computer 22A loads the code for all exceptions 
associated with the method call before generating an RPC to execute the method. 

More specifically, for each possfeie exception condition, there is a corresponding object class. When an exception's 
object class is instantiated, an object instance is created that includes a method (La, an executable program) for 
responding to or otherwise processing the corresponding exception. Thus, in the prior art system, when a client appli- 
cation program initiates an RPC to invoke an object method, if the RPC references a long list of exception object 
classes, all those exception object classes will need to be instantiated in the address space of the client application pro- 
gram 34 before the RPC in the client subcontract 40 can even transmit the method call to the server computer 24. 

While the exception information for some of these exceptions (i.e., instances of some of the exception object 
classes) may be available on the client computer 22, in most cases at least some of the exception object classes will 
not be resident on the client computer 22. For those exceptions that do not have corresponding exception procedures 
(i.e.. exception code) on the client computer 22, the client computer 22 is forced to retrieve the exception procedures 
from remote computers, such as server 24N. shown in Figure 1 . Furthermore, a separate (x>mrnunication session is typ- 
ically required to obtain each exception procedure (i.e., exception code). Consequently, the process of gathering excep- 
tion code can be relatively time consuming. This processing penalty is especially unfortunate since in most cases the 
exception code is not required by the client computer 22. 

A method call in the present embodiment does not reference each exception associated with the method call. Con- 
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sequent!* the different exceptions are not loaded initially. They are only loaded if an exception is delivered. Thus, with 
the present embodiment only the method call is processed initially, resulting in faster performance. The improved per- 
formance is only unavailable in the relatively rare event that an exception is processed. 

As shewn in Figure 5, each identified method, say the method associated with Descriptor_Ust_i, has an associated 
exception descriptor. The exception descriptor is a pointer. For example, relying upon the "get_weak_comparator 
example above, the exception descriptor is 
jgetjweak_comparatorExcepti^ 

The exception descriptor points to an exception list that has M exception subset lists. Figure 5 shows 
ExceptionJJstjc. Each subset list specifies one of the exceptions to the method call including the IDL short name, IDL 
long name, a repository identification, and any alternate identification for the exception. Each exception fist also 
includes an exception object identifier, which is used to locate exception code at run time. 

The exception descriptor concept used in this embocfi merit of the invention is shown in Figure 4. Note that the last 
entry in the subset descriptor list "DescrjptcrJjsM * is an exception descriptor that points to an exception fist. The reply 
generated by the server computer when executing a method may include any one of the entries within the Exception 
list, say, the exceptions associated with ExceptionJJsM , Exception JJst_3, or Exception_List_M. A specified server 
subcontract 58 uses its associated protocol to transmitthe exceptions. The client computer 22 then receives the excep- 
tions from the server computer 24. 

In accordance with the present embodiment, the diertsub(»ntract40storesacopyoftte 
with an exception descriptor. Thus, when the exceptions are received from the server computer 24, the client computer 
22 can match them to the exceptions in the exception list, using the technique previously disclosed in relation to identi- 
fying methods. 

The exception is then processed by relying upon an exception object identifier, which is used to retrieve the excep- 
tion code associated with the exception. Note in Figure 5 that Exception_Ust_x. like all other exception subset lists, 
includes an exception object identifier (Exception Object ID), which is a string name that specifies the object class to 
handle the exception. The code for the object class may be in a locaJ object repository 104. In the event that the object 
does not reside in the local object repository 104, the operating system 42 instantiates the object into the local object 
repository 104 by downloading code from another computer on the network, say server 24N of Figure 1. Thus, the 
remote object repository 106 of Figure 5 refers generally to any computer that is called to provide code for an object 
The code is then directed into the local object repository 104. The process of fetching code from the local object repos- 
itory 1 04 and the remote object repository 1 06 is simflar to prior art approaches, but the operation in the present inven- 
tion is executed after an exception has been returned, instead of when the method descriptors are constructed. 

The foregoing disclosure of an embodiment of the invention is summarized in reference to Figure 6. The first step 
associated with the process of Figure 6 is to generate a method call at a client computer 22 (block 110). As indicated 
above, the method call of the embodiment does not instantiate an exception's object class. Thus, the method call is han- 
dled without instantiating exception objects. 

The next processing step is to process the method call at the server computer 24 (block 1 1 2). As indicated above, 
the attempt to process the method call results in the server computer 24 identifying an exception. The exception is then 
passed to the client computer 22 (block 1 14). 

When the client computer 22 receives the exception, it attempts to match it to the exceptions in the exception list 
that it stores (block 1 16). Each subset of the exception list (say, ExceptionJJst_M) is associated with a single exception, 
and each subset has a corresponding exception object identifier (Exception JDbjectJD, as shown in Figure 4). The 
exception object identfier is used to load exception code into the client computer (block 1 1 8). Finally, the client compu- 
ter processes the exception code to respond to the exception generated by the method call (block 120). 

In view of the foregoing, the benefits of the present embodiment are manifest In accordance with the embodiment 
client computers 22 operate much faster because they load less information when a method is invoked. Specifically, 
they only toad the code needed to process the method can. In the relatively unusual event that the method call is unsuc- 
cessful, then the exception code associated with the method is expeditiously loaded. 

Claims 

1. A method for handling method calls in a client/server computer system, said method comprising the steps of: 

matching an exception generated by a server computer to exceptions in an exception list to obtain an exception 
object identifier; 

loading into said client computer exception code corresponding to said exception object identifier; and 
processing said exception code to respond to said exception of said method call. 

2. The method of claim 1 further comprising the following steps performed before said matching step: 
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receiving at a server computer a method call generated by a client computer; 
attempting to execute said method can on said server computer ; 
generating an exception to said method call in response to said attempting step; and 
passing said exception to said client computer to perform said matching step. 

5 

3. The method of claim 2 wherein said passing step includes the step of passing said exception in a protocol-depend- 
ent format. 

4. The method of claim 2 wherein said matching step includes the step of using an exception list with a plurality of 
w subset lists, each of said subset lists corresponding to a specified exception and including a set of entries corre- 
sponding to different protocol-dependent statements used to characterize said specified exception. 

5. The method of claim 2 wherein said toadSng step includes the step of loading said exception code from a cornputer 
other than said client computer when said exception code is not resident on said client computer. 

15 

6. The method of claim 2 further comprising the steps oh 

locating within said method call a method descriptor specified in a protocol-dependent format; 
assigning an index value upon matching said method descriptor to a selected protocol-dependent statement in 
20 a list of protocol<lependent statements; and 

passing said index value to a protocol-independent processing module of said server computer, wherein said 
computer server returns to said client computer a reply based upon said index value. 

7. A computer readable memory that can be used to direct a client/server system to function in a specified manner, 
25 comprising: 

method exception information stored in said memory, said method exception information including an excep- 
tion list specifying a set of exceptions; and executable instructions stored in sad memory, said executable 
instructions including: 

30 

instructions to generate at a server computer of a client/server system an exception in response to a 
method call from a client computer of said client/server system; 
instructions to pass said exception from said server computer to said client computer; 
instructions to match said exception to exceptions in said exception list to form an exception object identi- 
35 fier; 

instructions to load into said client computer exception code corresponding to said exception object iden- 
tifier; and 

instructions to process said exception code to respond to said exception of said method call. 

40 8. The computer readable memory of claim 7 wherein said instructions to pass said exception from said server com- 
puter to said client cornputer include instructions to pass said exception in a protocoKJerjendent format 

9. The computer readable memory of claim 7 wherein said instructions to match said exception to exceptions in said 
exception fist include instructions to use an exception fist with a plurality of subset lists, each of said subset lists 

45 corresponding to a specified exception and including a set of entries corresponding to different protocol-dependent 
statements used to characterize said specified exception. 

10. The computer readable memory of claim 7 wherein said instructions to load into said client computer exception 
code corresponding to said exception object identifier includes instructions to load said exception code from a corn- 
so puter other than said client computer when said exception code is not resident on said client computer. 

11. The computer readable memory of claim 7 further comprising: 

instructions to locate within said method call a method descriptor specified in a protocokiependent format; 
55 instructions to assign an index value upon matching said method descriptor to a selected rxotocoJ-dependent 

statement in a list of protocol-dependent statements; and 

instructions to pass said index value to a protocol-independent processing module of said server computer, 
wherein said computer server returns to said client computer a reply based upon said index value. 
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ExceptionJDescriptor 



DescriptorJJsUM 

DescriptorJjst_N_1 (IDL Short Name) 
Descriptor_List_N_2 (IDL Long Name) 
Descriptor JJst_N_3 (Repository ID) 
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